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(57) ABSTRACT 

A method of memory management in a computer sys tem 
co mprising mem ory. The method includes the steps of: in 
res ponse to reques ts for allo catiop of memory bloc ks that 
remain allocated for different durations, allocating each 
memory block from one of a plurality of regions in the 
mem ory base d on the duration that the memory block is to 
remain allocated : and maintaining a plurality of memory 
se gment s of one or more sizes in the memory, and in 
response to a request for allocation of a memory block if the 
requested block size is less than a predetermined siz e, then 
all ocating the requested block from among said segments, 
otherwise allocating the requested block from another por- 
tion of the memory. The number of data segments are 
changed in relation to memory requests. Further at least a 
portion of the memory is allocated to a cache having one or 
more buffers. The cache buffers can be allocated for non- 
cache use, including increase the number of said data 
segments, and are then deallocated back to the cache. 

38 Claims, 16 Drawing Sheets 
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SELF-TUNING MEMORY MANAGEMENT 
FOR COMPUTER SYSTEMS 

FIELD OF THE INVENTION 

The present invention related to memory management, 
and in particular, to memory management for computer 
systems including file servers. 

BACKGROUND OF THE INVENTION 

Ne tworked computer systems ty pically include at least 
one fil e server data pro cessinp ; system . A file server can 
comprise a c omputer including a processor, memory, com- 
mu nication in terface, and st orage device suc h as a disk 
drive, configured by a file system program to provide file 
server functions. The performance of a file server is depen- 
dent upon several factors, o ne of the most important o f 
wh ich is t he jffiount of_physical memo ry (e.g., RAM) 
available for buffering/caching disk reads/writes. The lim- 
ited amou nt of memory leads to intense competition 
between me hie system and other system needs for memory. 
Further, the speed of memory block allocation for hufferipg 
data upon de mand degrades over time primarily due to 
m emory TTagmentaiio n. Without an abunda ppft physipfll 
memory, e fliciept memory manaeemept l< s rftgnji-ed tn ensifre 
s iisjflined performs nr e .withooiljifigtadatiQP • 

However, conventional memory management methods, 
while enhancing performance in one network environment, 
often degrade performance in another. Even within one 
network environment, load changes from hour to hour can 
very widely and static memory management and tuning 
methods lead to degradation of the file server performance 
in many circumstances. Some conventional methods attempt 
to manage competition for memory by adding more physical 
memory or by using virtual memory methods, whicli rely on 
paging memory to buffer data to and from the storage system 
(e.g., disk drive). However, adding more physical memory is 
costly, requires space and consumes power. Further, virtual 
memory methods invariably lead to slow processing and 
unacceptable file server performance as they defeat the 
purpose of file system caching. Other conventional systems 
attempt to solve memory fragmentation by threading adja- 
cent memory blocks together when freed, However, memory 
rethreading takes time, leading to reduced file server per- 
formance. 

There is, therefore, a need for a memory management 
method and system for network file servers which acceler- 
ates memory allocation/deallocation for buffering data, 
reduces memory fragmentation, increases available memory 
for the file server file system 1/0 buffers while optimizing 
the amount of memory available for other uses, and manages 
competition for different memory uses, across different 
network environments and over time within one network 
environment. 

BRIEF SUMMARY OF THE INVENTION 

The present invention satisfies these needs. In one 
embodiment, the present invention provides a method of 
managing memory including the steps of: in response to 
requests for allocation of memory blocks that remain allo- 
cated for different diu-ations, allocating each memory block 
from one of a plurality of regions in the memory based on 
the duration that the memory block is to remain allocated; 
and maintaining a plurality of memory segments of one or 
more sizes in the memory, and in response to a request for 
allocation of a memory block if the requested block size is 
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less than a predetermined size, then allocating the requested 
block from among said segments, otherwise allocating the 
requested block from another portion of the memory. 
Preferably, in response to requests for allocation of long 
5 term memory blocks, long term memory blocks are allo- 
cated from a first region of the memory; and in response to 
requests for allocation of short term memory blocks, short 
term memory blocks are allocated from a second region of 
the memory. The number of data segments are changed in 
relation to memory requests. Further at least a potion of the 
memory is apportioned for other use such as to a cache 
having one or more buffers. The cache buffers can be 
allocated for non-cache use, including increase the number 
of said data segments, and are then deallocated back to the 
cache. 

In another aspect the present invention provides a 
memory manager including means for implementing the 
above steps in a computer system comprising memory and 
a CPU for managing the memory. Further, the present 
invention provides a computer program product comprising 
a computer readable medium including program logic for 
configuring said computer system to perform the steps of 
managing memory according to the present invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 

25 These and other features, aspects and advantages of the 
present invention will become understood with reference to 
the following description, appended claims and accompa- 
nying figures where: 

FIG. 1 shows a block diagram of an example architecture 
of an embodiment of a computer network in which the 
present invention can be implemented; 

FIG. 2 A shows a block diagram of an example system 
architecture of an embodiment of the file server of FIG. 1; 

FIG. 2B shows a block diagram of an example functional 
architecture of the file server of FIG. 2A; 

FIGS. 3A-3E show example memory maps according to 
an embodiment of the memory management of the present 
invention; 

FIGS. 4-5 show example flow diagrams of embodiments 
of the memory management method of the present inven- 
tion; 

FIGS. 6A-B show example memory maps for a heap 
according to the present invention; 

FIGS. 6C-D show example memory maps of the heap of 
FIG. 6B for long term memory allocation; 

FIGS. 6E-F show example memory maps of the heap of 
FIG. 6B for short term memory allocation; 

FIGS. 6G-H show example memory maps of the size 
queue heap allocation and growth; 
50 FIGS. 6I-J show another example memory map wherein 
a size queue (FIG. 61) grows by borrowing a cache buffer 
(FIG. 6J); 

FIGS. 7-12 show example flow diagrams of embodiments 
of the memory management method of the present inven- 
55 tion; and 

FIG. 13 shows a block diagram of an example architecture 
of an embodiment of another computer system in which the 
present invention can be implemented. 

To facilitate understanding, identical reference numerals 
^0 have been used, where possible, to designate structurally/ 
functionally identical or similar elements that are common 
throughout the figures. 

DETAILED DESCRIPTION OF THE 
g5 INVENTION 

In one embodiment, the present invention provides a 
method of managing competition for memory by various 
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processes in computer systems which utilize a cache system 
for managing at least a portion of the memory. For example, 
in a computer system without virtual memory which relies 
upon cache memory (e.g., in order to increase performance 
for repetitive disk reads), requests by processes in the 
computer system for allocation of general purpose memory 
can lead to wasteful competition for limited memory 
between cache and general purpose needs. In one 
embodiment, the present invention manages such competi- 
tion problems in such computer systems, and minimizes 
memory fragmentation and dynamically tunes memory 
resources to minimize memory waste, in order to maximize 
the cache resource. For example, a memory management 
method and system according to the present invention can be 
implemented in network systems, network computers, sub- 
scriber management systems, network file servers, etc. 

In one example version, the present invention can be 
implemented in a computer network including a network file 
server and a file system. FIG. 1 shows a block diagram of an 
example architecture of an embodiment of a computer 
network 10 (e.g. local area network) in which the present 
invention can be implemented. The network 10 comprises a 
hub 12 to which a file server 14, an application server 16 and 
client computers 18 (e.g., personal computers) are intercon- 
nected for communication therebetween and with other 
computer/network systems via a router 20. The file server 
provides functions, including data storage and retrieval, for 
at least the network. 

FIG. 2A shows a block diagram of an example system 
architecture of an embodiment of the file server 14 of FIG. 
1. The filer server 14 comprises a storage device 22 such as 
a disk drive, CPU 24, memory 26 and a communication 
interface 28 (e.g., Ethernet Port) connected to the hub 12. 
FIG. 2B shows a block diagram of an example functional 
architecture of the file server 14 of FIG. 2 A, wherein the file 
server 14 is configured to provide functions including 
memory management and file system management. In one 
embodiment, memory management methods according to 
the present invention are implemented as a memory manager 
module (e.g., software) 30 in an operating system (OS) 29 
for execution by the CPU 24 to configure the file server 14 
to manage the memory 26. The operating system 29 can 
further include high level functions including functions for 
implementing a network file server including e.g. protocol 
handling, user interface functions, etc. In general, the 
memory 26 includes a cache 32 for use by e.g. a file system 
software, and a general purpose heap 34 for other memory 
requirements/allocations. 

In one embodiment, a memory management method 
according to the present invention, implemented as the 
memory manager 30, provides rapid memory allocation and 
de-allocation, reduced memory fragmentation, maximizes 
the amount of memory available for a cache (e.g., file system 
I/O buffers) while optimizing the amount of memory avail- 
able for other uses, and manages competition for different 
memory uses by system self-adaptation to different usage 
levels across different network environments and over time 
within one network environment, including self-tuning to 
optimize performance to a variety of environments and 
dynamic conditions. 

Referring to FIG. 3 A, in one version, to effectively 
eliminate fragmentation of the memory 26, at file server 
startup/initialization the memory manager 30 segregates 
memory block allocations that are to remain allocated for 
long periods of time, long term (LT) memory blocks, to a 
first region LT memory 36 of the memory 26 from the heap 
34 (preferably the low address end of the memory 26). 
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Further, the memory manager 30 segregates memory block 
allocations that are to remain allocated for short periods of 
time, short term/transient (ST) memory blocks, to a second 
region ST memory 38 of the memory 26 from the heap 34 

5 (preferably the high address end of the memory 26). Refer- 
ring to FIG. 3B, the memory manager 30 then creates and 
maintains size queues 40 (SQ) including plurality of 
memory segments 42 of varying predetermined sizes, or 
separate memory pools, in a third region of the memory 
from the heap 34, to satisfy smaller short term efiGcient 
memory block allocation requests (e.g., requiring few/brief 
allocation steps). As such, smaller short term memory block 
allocations are segregated by the use of the size queues 40 
(e.g., six queues), dedicated to predetermined sizes of 

J J memory allocation requests (e.g., memory block allocations 
ranging fi^om 32 up to 1024 bytes, with odd sizes rounded 
up). 

In addition to the size queues 40, the ST memory 38 can 
also be used to satisfy short-term memory block allocations, 

20 however, preferably size queues 40 are utilized for smaller 
short term memory block allocations (e.g., 1024 bytes or 
less) while the ST memory 38 is utilized for larger short term 
memory block allocations. In one example, after long term 
memory block allocations are processed (e.g., after 

25 initiahzation), thereafter the memory manager 30 treats all 
LT memory allocation requests as ST requests. Size queues 
40 are used for small sized requests. This avoids fragmen- 
tation by handling memory allocation requests according to 
size and by duration. LT memory allocation requests can be 

3Q handled differently from ST memory allocation requests 
after initialization, if a large memory allocation request is 
preferentially allocated from ST memory or by cache. 

As such a memory management method according to the 
present invention effectively eliminates fragmentation of the 

35 memory 26 in a computer system including memory gen- 
eraUy partitioned/apportioned for at least cache use and 
general purpose (e.g., such as in the networked file server 
appliance 14). The method of the present invention allevi- 
ates fragmentation of the memory by preventing mixing of 

40 small and large memory block allocations, and by prevent- 
ing mixing short and long term memory block allocations, in 
the memory 26. There is no need for processing time to 
thread memory together from smaller adjacent buffers to 
larger ones in the size queues 40, nor is it necessary to keep 

45 track of the positions of buffers in the size queues 40. 
Referring to FIG. 3C, the memory manager 30 provides 
control of almost all idle memory to the file system for use 
as the file system cache 44 (FS cache) including buffers 46, 
The requested memory block allocations are segregated 

50 by duration (e.g., long term, short term, etc.) and by use of 
size queues 40. Further, the separate memory pools/size 
queues 40 are not threaded together, wherein memory allo- 
cations take memory segments 42 from the size queues 40 
and memory deallocations return memory segments 42 to 

55 the size queues 40, without further processing. The size 
queues 40 allow reduction of processing overhead for 
buffer/segment 42 threading and eliminate ordering by posi- 
tion. The size queues 40 can be utihzed as pools of memory 
for allocation similar to a heap. 

60 In another embodiment, according to the memory man- 
agement method, the memory manager 30 d ynamically 
tu nes the size queues. 40 (e.g., by dynamically changing the 
num ber of data segments 4 2 therein) to _afford adaptation to 
v arying memory requirements in the file server . The method 

65 allo ws managing competition for memory betweea the file 
sy stem cache buffers 46. and other me mory requirements o f 
the file server 14 . After syst em initialization/start-up, und er 
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control of the memory manager 30, memory block alloca- when no longer required by system needs. For example, a 

tions in response to memory requests are limited to no more background trimming process determines if all segments 42 

than is needed for a single file system cache buflfer 46 (e.g., within a single borrowed file system cache buffer 46 in the 

8192 bytes). Further, all memory remaining in the heap 34 SQ growth 50 are free, so that buffer 46 can be returned to 

after initial long term memory block allocations 36, size 5 the file system cache 44. As such, dynamic tuning by using 

queue 40 creation and optionally the ST memory 38, is the file system cache buffers 46 to temporarily increase size 

provided to the file system for use in the cache 44 to queues 40 (and/or heap space), allows managing competi- 

maximize the number of buffers 46 therein. tion for memory. 

The memory manager 30 manages competition for In the example operation shown FIGS. 3A-E, mapping of 

memory by providing most of the available memory to the the memory space by the memory manager 30 includes five 

cache 44 arid then borrowing one or more of the cache states, wherein: (1) as shown in FIG. 3 A, the memory space 

buffers 46 when needed for memory block allocations of a in heap 34 is divided to LT memory 38 for long term (LT) 

certain size, for use as the size queues 40, for use as the ST allocations from low address memory, and to ST memory 38 

memory 38, etc. Thereafter, the memory manager returns for short term (ST) allocations from high address memory, 

(deallocates) said borrowed buffers 44 back to the cache 40 (2) as shown in pl©r'Ji3,_si^ queues (SQ) 40 are Iheril 

when released by the operating system. created asppols of memory including a minimum number of\ 

As such, in one version the memory manager 30 dynami- memory segments 42 allocated from e.g. the low address 

cally changes the dividing line (e.g., fuzzy dividing line) in memory region, wherein allocations from size queues 40 are 

memory between the cache 40 and the heap 34 comprising for short term memory blocks; (3) as shown in FIG. 3C, 

the SQ memory 40 and the ST memory 38, in relation to 20 when system initialization is complete, most unallocated 

memory allocation requests. In one example, under the memory is provided to the file system (FS) for use as cache 

control of the memory manager 30, memory block alloca- 44; (4) as shown in FIG. 3D, thereafter, if size queues 40 

tions of a predetermined size (e.g., 8192 bytes) are borrowed need to grow as described above, the needed memory 50 is 

directly from the cache 44 (e.g., from cache buffers 46 of borrowed from the file system cache 44; and (5) as shown in 

8192 bytes in size) and returned directly to the file system 25 FIG. 3E, when size queues 40 are trimmed back to minimum 

cache 46, without requiring memory threading or fUrther by returning the borrowed memory 50 to the file system 

processing. The memory manager 30 borrows memory from cache 44, the memory layout returns to the post- 

the cache 44 when for example: (a) the ST memory 38 is initialization state in FIG, 3C. By performing self- tuning 

exhausted, wherein the memory manager 30 borrows a (e.g., FIGS. 3E)-E), the memory manager 30 adapts itself to 

buffer 46 to satisfy allocation requests above a predeter- 30 a wide variety of network environments, which a networked 

mined size (e.g., 1024 bytes), (b) no ST memory 38 is file server appliance can expect to encounter, 

reserved, wherein the memory manager 30 borrows one or As such, during startup, all memory (not previously 

more buffer 46 from the cache 40 to satisfy one or more dedicated) is in the form of the heap 34, comprising the LT 

allocation requests, or (c) the memory manager distin- memory 36, the ST memory 38, and the SQ memory 40. 

guishes between allocation requests and determines that 35 After startup, the LT memory 36 is no longer available for 

borrowing one or more cache buffers 46 is more efficient general use as it has been allocated for long term allocations, 

where e.g. an allocation request is for long term memory, After startup, the memory manager 30 converts as much 

and even though the system is fully initialized, the memory remaining memory in the heap 34 as possible to the cache 

manager allocates long-term memory requests from the 44. Therefore, what remains in the heap 34 for general 

cache 44 (e.g., the file system requests memory and the purpose allocation arc the minimum reserved SQ memory 

memory manager 30 allocates the memory from the cache 40 and a small reserved portion of the heap 34 for the ST 

44), Etc. memory 38. The cache 44 is not a heap and so not for general 

Kg£efBBg-t5TTC>3D, further, the memory manager 30/ use allocations, rather the cache 44 is for specialized use 
increases" the number of segments 42 in the size queues 401 such as for the file system I/O buffers. When needed, cache 
when depleted by borrowing one or more file system cache! 45 buffers 46 are borrowed to temporarily provide heap 

buffers 46 to create additional data segments 42, included ir memory for general allocation, and then returned to the 

SQ growth 50, for one o r more size queues 4 0. Each size cache 44. The ST memory 38 is structured as a heap (small 

qu eue 40 can grow independently, borrowi ng one or m or< heap) comprising ordered link list of memory blocks which 

file sy stem cache buffers 4 6. thereby allowing the file scrvei are unthreaded and threaded when allocated and deallocated, 

14 t cL S6tf-tunc_ to the sizes of allocations required ^ b\ 50 respectively, (described further below). Optionally, the 

diffe rent networking environments- ^ memory manager 30 can convert all ST memory 38 to the 

The file system cache 44 is for the use of the file system, cache 44, and then fulfill all allocation requests above the 

while the ST memory 38 and the size queues 40 in the heap size queue segment limi t (e.g., 1024 bytes) using borrowed 

34 serve the system as a whole for general memory needs FS cachejbuiters 4<>. * ^ 

such as the file server's operating system needs for allocat- 55 The method of preventing memory fragmentation can be 

ing memory for storing information including e.g. network used alone or with the methods for managing competition 

protocol specific code to store information about a user and for self-tuni ng. Further, size queue dynamic tuning can 

connection, or administrator utility for sorting a list of be utilized without the method'for managing memory com- 

currently open files or system database needs for block petition. In that case, instead of borrowing buffers 46 from 

writes to flash memory, or many other uses. Both the ST 60 file system cache 44 to grow the size queues 40, the memory 

memory 38 and the size queues 40 can borrow memory from manager 30 can borrow the additional needed memory from 

the file system cache 46 (e.g., FIG. 3D) and return the a general heap such as the ST memory 38. Further, the 

borrowed memory (e.g., FIG. 3E), to manage competition competition for memory between the file system cache 44 

for memory, wherein dynamic borrowing/returning memory and the ST memory 38, can be managed as described 

provides self tuning. 65 without preventing fragmentation or performing seff-tuning. 

The size queues 40 can be passively trimmed to allow The methods for preventing fragmentation (e.g., segre- 

return of borrowed buffers 46 to the file system cache 44 gating allocations by duration and the use of size queues 40 
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) can be accomplished without method for managing com- F\G. S shows an example flow diagram of an embodiment 
petition for memory (e.g., between cache 44 and general ofstep 60 in FIG. 4, for initializing the memory manager 30. 
purpose size queues 40 and heap 38) or dynamic mning During initial system startup (step 80), the memory manager 
(e.g., growing the size queues 40 on demand and trimming 30 is initialized by steps including: establishing a heap 34 in 
them passively). However, without utiUzing the method for 5 the memory 26 by creating a heap pool header 90, shown in 
managing competition for memory, sufficiently large KICL-fiA, to manage all memory available for general- 
amounts of memory must be initially reserved for the size purpose allocation (step 82), and establishing a block header 
queues 40 to avoid competition with the FS cache 44, 92 at the start of each contiguous block of memory 94 
wherein cither more memory is required or else less memory available for allocation^-iniliali&ng the entirety of each 
can be dedicated to the FS cache 44. The methods for block 94_^ilh-a4aiowB-yalue (e.g., *M'), and estabJisEing a 
preventing fragmentation can also be implemented without lin k list 96 connected to the heap p ool header 90 to chain 
the methods for dynamic tuning. \vfi^rein the size queues 4 0 together all of the block s 94 (step 54\ leading to a system 
and the ST memory 38 include sufficient memory to satisfy me mory map as shown by example in FIG. 6A. 
th e maximum memory use the system can anticipat e. This Referring to ^G. 6 B, each block 94 can be divided into 
requires upper limits on the size queues 40 and the ST one or more buffers/blocks 95 for general purpose 
memory 38. allocation, wherein an allocation header 98 is established at 

Farther, the methods for dynamic tuning can be imple- the bcg inninR of each bloc k 95 to manage each block 95 for 

mented without the methods for managing competition general ^urpose use/a llocation. The allocation headers 98 

between the FS cache 44 and general use allocations from for allocated block s 95 are marked as 'allocated', and the 

the size queues 40 and the ST memory 38. Dynamic tuning allocaJinn headers for -lhe remaining allocableJa lccks 95 are 

is an aspect of managing competition, but can be imple- 20 marked jis 'fre e' and cha ined together in a two-way free 

mented merely to manage the competition for memory mem ory link Ji §t 100 maiatamgd m memory address order 

between the different size queues 40 and the ST memory 38. and connected to the heap pool header 90 (step 86), leading 

While it would be entirely possible and appropriate to to a system memory map as shown by example in FIG. 6B. 

implement dynamic tuning without ooncera for the needs of The memory manager 30 then awaits requests from the 

an FS cache 44, it is preferable to implement methods for 25 system operating system (OS) (step 88). 

dynamic tuning and preventing fragmentation together. F^fiJLshows an example flow diagram of an embodiment 

Implementing the methods to manage memory competi- of step 62 in FIG. 4, for allocation of long term memory 

tion between the FS cache 44 and general allocation needs from the heap 34 during startup as shown in FIG. 6B. Upon 

(e.g., by providing all available memory to the FS cache 44 receiving a request from the operating system for long term 

then borrowing back buffers 46) can be implemented with- 30 allocation of a memory block (step 102), the memory 

out using dynamic tuning. As such, a borrowed FS cache manager 30 performs steps including: traversing through all 

buffer 46 can be utilized for general ST memory 38, rather available (free) allocation headers 98 in the heap 34, starting 

than for specific size queue growth. Additionally, it is not at low memory address (LT memory 36), to find the first 

required to return borrowed buffers 46 back to the FS cache memory block 95 large enough for the size of requested 

44 (i.e., tuning one way — borrowing but not returning FS 35 memory block (step 104); determining if the found allocable 

cache buffers 46). However, one way tuning can lead to memory block 95 is significantly larger than the requested 

inefficient memory use over time, while excluding size size (step 106); if not, as shown by example in FIG. 6C, 

queues from self- tuning can lead to size queue exhaustion removing the allocation header 98 of the found block 95 

and allocation failure, or fragmentation. As with dynamic from the link list 100 and re-linking the link list 100 (step 

tuning, it is preferable to manage competition between the 40 otherwise, as shown by example in FIG. 6D, unthread- 

FS cache 44 and general purpose needs (e.g., the size queues ing a portion 95a of the found block 95, the portion 95a 

40 and/or the ST memory 38), while alleviating fragmenta- being of the size requested, by adjusting the size in the 

tion. Therefore, the methods of managing competition and found/existing allocation header 98 of the found block 95 

dynamic tuning collaborate to prevent memory waste, and (e.g., subtracting the requested size from the size of the 

are not dependent upon minimizing fragmentation. Over 45 allocation header 98) and creating a new allocation header 

time, fragmentation consumes memory and processing time, 98fl in memory beyond the portion 95a of the block 95 for 

unless the operating system is restarted regularly after only the remaining free portion 95b of the found block 95, and 

short duration of running to reinitialize the memory. A replacing the allocation header 98 in the allocation header/ 

combination of the methods for managing competition, free link list 100 with the new allocation header 9Ha by 

dynamic tuning and minimizing fragmentation can provide 50 placing the new allocation header 98cj in the link list 100 

most efficient memory management, (step 110); and marking the existing allocation header 98 for 

R£L.4-&hows an example top level flow diagram of an said memory portion 95fl as 'allocated* (not free) and 

embodiment of the memory management method of the returning the memory address immediately following the 

present invention implemented in one version as the existing allocation header 98 to the operating system 

memory manager 30, including the steps of: initializing the 55 requestor (step 112). 

memory manager 30 (step 60), allocating long term memory Threading includes the steps of joining two adjacent 

buffers from low address end of memory (step 62), buffers (e.g., blocks 95) of memory into a single buffer 

allocating/deallocating temporary/short term memory buff- governed by only one allocation header 98. Threading can 

ers from high address end of the memory 26 (step 64), be performed when a freed buffer is adjacent to another free 

generating size queues 40 and allocating/deallocating 60 buffer, to join into a larger buffer, thereby reducing frag- 

memory blocks from segments 42 therein (step 66), after mentation. Unthreading includes the steps of dividing a 

system initiahzation/startup, managing memory to increase single buffer (e.g. block 95) with a single allocation header 

performance (step 68), increasing/decreasing size queues 40 98 into e.g. two smaller buffers with two corresponding 

in relation to memory requests (tuning) (step 70), and allocation headers 98 (e.g., when part of an available buffer 

performing trimming of size queues 40 (step 72). One or 65 is allocated, and the remaining part is left behind as free), 

more of the above steps can be repeated. Example embodi- FIG. 8 shows an example flow diagram of an embodiment 

ments of the above steps are described further below. of step 64 in FIG. 4, for temporary/short term aUocation/ 
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deallocation of memory blocks from the heap 34iif£lG_fi5. Flfi^ shows an example flow diagram of an embodiment 

Upon receiving request from the operating system for short of step 66 in FIG. 4, for establishing an dcreating size queu es 

term allocation of a memory block (step 120), the memory 40 f or memory allocations/deallocatioDs based upon siz e, 

manager 30 performs steps including: traversing through all Aft er long term allocations trom the heat) 34 (sten 160\5ut 

available (free) allocation headers 98 in the heap 34, starting 5 bef ore the file server s operating system is fullv initialize d, 

at high memory address (ST memory 38), to find the first th e memory maa agcr 30 es tablishes size queues 40 for short . 

memory block 95 that is large enough for the size of memory term all ocations of small blocks of memory , by steps includ- \ 

requested (step 122); determining if the allocable memory in g: for a memory 26 of certain size estimating the m ini- 

block 95 is significantly larger than requested size (step mum number of segments 42 require d to create an efficient 

124); if not, as shown by example in FIG. 6E, removing the 10 size queuejfi^e^., 100 segmen ts of memory 32 bytes long 

found aUocation header 98 from the free link list 100 (step each); calculatmg.the amoum of memory ncccssao. 10 create 

126), and returning the memory address immediately fol- th e size queue 40 a s a heap/memory pool (e.g 100 segments 

lowing the found aUocation header 98 to the operating ^^ti''^t.^r^/^''a-l?' ""5 l""allocation headers 98 plus 

^ ^ * ^^m .1. • u u onc block header 92): allocatmg the memory ETom thc heap 

system requestor (step 130): otherwise, as shown by , . , ur u- u * An / t-i^o 

1 • T-Ti-. . . i_ pool 34; and estabhshmg each size queue 40 (e.g., FIGS, 

example m FIG. 6F, unthreading the requested memory by 15 ^q-H) similar in structure to the heap 34 described above 

modifying the size in the found/existmg allocation header 98 (pjQg ^^^^-^ segments 42 in memory 

(e.g., subtractmg the requested size from the size m thc (preferably contiguously allocated), separated by a Uocatio n 

found aUocation header 98); dividmg the block 95 to a h eaders 98 for managing each segment 42 (steplSi); 

portion 95a to remain free and a portion 95^> of the requested creating a fr ee memory link lis t 100 fo^Jbs^giijiueus. 40 

size to be aUocated; creating a new allocation header 98a 20 c haining all of the allocation headers 98 together, much the 

beyond a portion 95a of the found block 95 in memory to same way as shown in FIGS. 6A-B and described above 

manage the portion 9Sb to be aUocated (unlike allocation (step 164); repeating steps 162 and 164 for each size queue 

from the low address of memory for long term allocations, 40 (e.g., multiple size queues of data segments of 32 bytes, 

the allocation header link Ust 100 is not altered here) (step 64 bytes, 128 bytes, 256 bytes, 512 bytes, 1024 bytes etc.) 

128); marking the new aUocation header 98a for said 25 (step 166); and waiting for requests from the OS (step 168). 

memory portion 956 being aUocated as 'allocated' (not free) Upon receiving operating system requests for short 

and returning the memory address immediately foUowing memory allocations at or below the size of the largest 

the new allocation header 98a to the operating system segments 42 (e.g., 1024 bytes) in a size queue 40 (step 170), 

requestor (step 130). the memory manager 30 performs steps including: deter- 1 

Upon release by the operating system of short term 30 mining which size queue 40 to utiUze to satisfy the request 

aUocated memory (step 140), the memory manager 30 (step 172). For example, a jump table of e.g. 32^slotscan be I 

performs steps including; finding the allocation header 98 in utilized, wherein bv takiq^ the requested size minus one an d / 

the heap 34 (FIGS. 6B,E-F) for a memory block 95 being dividing the result by 32, an appropriate size queue 40 witW 

freed, located immediately before the memory address pro- se gments 42 sufficiently large to satisfy the requesj, i^ 

vided for the released block 95, and marking the found 35 selected Oire cUy. . ^ 

aUocation header 98 as 'free' (step 142); then attempting to The memory manager 30 selects a size queue 40 in 

perform threading by determining if there is a valid free response to aUocation requests, by e.g. subtracting 1 from 

aUocation header 98 immediately foUowing the block 95 the requested memory size, dividing the result by 32 and 

being freed (step 144); if not, traversing Uirough the link list truncating thc answer to an integer, to quickly generate a 

100 in heap 34 from highest memory address to lowest 40 number between 0 and 31. (e.g., for request of 32 bytes, 

memory address to find the position in the free Unk Ust 100, trunc((32-l)/32)=0; for a request 33 bytes, trunc((33-l)/ 

in memory address order, where the allocation header 98 of 32)=1, for a request of 1024 bytes, tmnc<(1024-l)/32)=31; 

the block 95 being fi*eed should be inserted (step 146); etc). A 32 member array (e.g., jump table) is maintained, 

otherwise, if a valid aUocation header 98 exists immediately providing 32 slots, wherein the calculated values are 

following the block 95 being freed, and the memory block 45 between 0 and 31 (array slot number). If the calculated value 

corresponding to said foUowing allocation header is also is lor 2 then jump to a size queue with 64-byte segments 42; 

free, then threading the block 95 being freed to the imme- if the calculated value is 3, 4, 5 or 6 then jump to size queue 

diately foUowing memory, by adding the size in said fol- with 128-byt6 segments 42, Etc. As such each member 

lowing aUocation header 98 to the size in the allocation points to the proper size queue (i.e. 2. 64. 64, 128. 128, 128, 

header being freed, and removing said following allocation 50 128. 256, . . . ). Therefore, with minimum processing, the 

header from the free link list 100, marking it as no longer memory manager 30 quickly resolves a size queue 40 to 

valid (step 148). aUocate memory from. When segment allocations are freed 

The memory manager 30, then performs steps including: back to the size queue, the size queue pointer in the 

determining if the allocation header 98 for the memory allocation header for a given segment 42 is utiUzed to find 

immediately preceding the allocation header 98 of the block 55 the appropriate size queue. However, instead of the pointer, 

95 being freed in the free memory Unk list 100 is contiguous other methods such as the using a lookup array similar to 

with the block 95 being freed (step 150); if not, adding the that used for allocation, can be utiUzed. 

aUocation header 98 for the block being fireed into the Unk The memory aUocation request is satisfied by obtaining a 

Ust 100 (step 152); otherwise if the aUocation header 98 segment 42 from the beginning of the free Unk Ust 100 in a 

immediately preceding the aUocation header of the memory 60 size queue 40 (step 174). Because all segments 42 in the 

being freed in the Unk Ust 100 is contiguous with the block selected size queue 40 are the same size, no searching for a 

being freed, threading the preceding memory to the block segment 42 of size large enough is necessary, and no 

being freed, by aUering the size in said preceding allocation ^unthreading* is required. The memory manager 30 then 

header 98, and marking the allocation header for the block return the memory address of the aUocated segment 42 to the 

being freed as no longer vaUd, wherein the free memory link 65 OS (step 176). 

Ust 100 is not altered (step 154); and returning to the Upon release of short term allocated memory at or below 

operating system (step 156). the size of the largest segments 42 (e.g., 1024 bytes) in a size 
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queue 40 (step 180), the memory manager 30 determines 
which size queue 40 the memory block should be released 
to by using the memory address of the size queue 40 
embedded within the allocation header 98 of the segment 42 
(step 182). The memory manager 30 then frees/deallocates 5 
the released segment 42 by marking the Allocation Header 
98 of the segment 42 as *free' and adding the allocation 
header 98 to the beginning of the free memory link list 100 
of the size queue 40 (step 184). The memory manager 30 
then return status to the OS (step 186). Because all segments 
42 in the size queue 40 are the same size, no threading is 
required, and because no threading is necessary, minimal 
processing is required to maintain the link list 100 in 
memory address order. The link list 100 is not maintained in 
address order, wherein a freed buffer is added to the begin- 
ning (or ending) of the link list 100. 

After allocation of long term and short memory blocks 
and the size queue 40 during startup, the heap 34 comprises 
the long term allocated blocks from the LT memory 38, short 
term allocated blocks from the ST memory 38, and the 20 
minimum size queues 40. Thereafter, after system startup, 
the memory manager 30 provides most of the free memory 
remaining in the heap 34 as cache 44 to the file system, 
leaving a small reserved amount to a minimum size queues 
40 and a small reserved amount to the ST memory 38 for 25 
general purpose allocations, thereby entering a performance 
based memory management mode described below. 

In one version, a minimum size queue 40 comprises a 
minimum number of segments 42 that are maintained in the 
size queue 40 without reduction. The minimum number can 30 
be tuned such that no size queue growth is necessary to 
achieve desired performance criteria. 

FIG. 10 shows an example flow diagram of an embodi- 
ment of step 68 in FIG. 4, for performance based memory 
management (e.g., tuning) after full system startup/ 35 
initialization. Upon receiving notification from the operating 
system that all file server modules have successfully been 
initialized (step 190), the memory manager 30 completes its 
initialization whereby all contiguous, free memory, except 
for small predetermined amounts reserved for the ST 40 
memory 38 and size queues 40, is allocated and provided to 
the file system to be used as the cache 44 including buffers 
46 (e.g. 8192 bytes each) (step 192), and the memory 
manager 30 then awaits requests from the OS (step 194). 

Thereafter, upon receiving memory allocation requests 45 
(step 196) the memory manager 30 treats requests for long 
term memory and short term memory allocations alike (step 
198), wherein the memory manager 30 determines if a 
requested memory block size is larger than that available in 
the segments 42 of the size queues 40 (step 200); if not, 50 
allocation requests less than or equal to the largest segment 
42 of the size queues 40 (e.g., 1024 bytes) are satisfied from 
the size queues 40 (step 204). Otherwise, the memory 
manager 30 then determines if there is sufiBcient memory in 
the ST memory 38 of the heap 34 to satisfy the memory 55 
allocation request (step 202), and if so, a requested memory 
block larger than the largest segment 42 of size queues 40 is 
satisfied from the ST memory 38 (step 206). The ST memory 
38 continues to maintain an address position link list 96 and 
unthreads and rethreads buffers as required (e.g., the same 60 
way as described above for the heap 34 in conjunction with 
FIGS. 6A-B), If stiflBcient memory is not available in the ST 
memory 38 to handle a non-size queue request, and if the 
request is less than a predetermined size (e.g., cache buffer 
size of 8192 bytes), then a single file system cache buffer 46 65 
is borrowed to satisfy the request (step 208). The borrowed 
file system cache buffer 46 is not divided into analler buffers 
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and so is not managed by the block link fist 96 or free Unk 
list 100 of the ST memory 38. The integrity of the borrowed 
file system cache buffer 46 is maintained (i.e., the buffer 46 
is not divided into smaller portions) to allow returning the 
borrowed cache buffer 46 to the file system cache 44 as soon 
as the single allocation is released. Upon satisfying the 
request, the memory manager 30 then returns the memory 
address following the allocation header 98 to the OS as the 
start of the memory allocated to the OS requestor to use for 
general purpose (step 210). 

When the operating system releases a short term memory 
block allocation (step 212), the memory manager 30 deter- 
mines if the allocation was satisfied from a borrowed file 
system cache buffer 46 (step 214), and if so the cache buffer 
46 Ls immediately returned to the file system cache 44 (step 
216) to optimize the file system cache 44; otherwise the 
released memory is returned to the structure that it was 
allocated from (e.g., the ST memory heap 38 or the size 
queues 40) as appropriate (step 218). The memory manager 
30 then returns to the operating system (step 220). 

FIG. 11 shows an example flow diagram of an embodi- 
ment of step 70 in FIG. 4, for adjusting the size queues 40 
in relation to memory requests/requirements. When the 
operating system requests the allocation of a memory block 
of a size to be satisfied by a size queue 40 (step 222) (i.e., 
the memory block size requested is no larger than the largest 
size queue segment 42), the memory manager 30 determines 
if a size queue 40 includes a free segment 42 to fulfill the 
request (step 224). If not, the memory manager 30 "grows" 
a selected size queue 40 by increasing the number of 
segments 42 therein. As shown by example in FIG. 6H, one 
or more file system cache buffers 46 are borrowed and 
treated as new blocks 97 to be added to the block list 96 of 
the size queue 40, and each block 97 is initialized to a known 
value (e.g., *Q*) (step 226). Each new block 97 is then 
divided into as many segments 42 of the required size for the 
size queue 40, and an allocation header 98 is created for each 
segment 42; any remaining memory of the predetermined 
size (e.g., 8192 bytes) of file system cache buffer 46 remains 
with the last size queue buffer to be created. For example, in 
a size queue 40 including segments 42 of size 64 bytes and 
allocation headers 98 of size 16 bytes, the number of 
segments 42 generated from the block 97 of 8192 bytes is: 
8192/(64+16)=102 segments 42 with 32 bytes left over. The 
unused 32 bytes remains along with the last segment 42 
created, untouched but governed by that last segment's 
allocation header 98, and accounted for when returned to FS 
cache 40. 

The size queue's free memory link list 100 is updated with 
the new allocation headers 98 and the new segments 42 (e.g., 
as described in relation to FIGS. 6A-B); and the size queue 
pool header 90 is marked as having grown/increased (step 
228). FIGS. 6I-J show another example wherein a size 
queue 40 (FIG. 61) grows by borrowing a buffer 46 (FIG. 
6J), If this is the first growth of a size queue 40 then a 
background process can be launched to periodically 
reorganize/trim the size queue 40 and attempt to release file 
system cache buffers 46 back to the file system (step 230). 
In satisfying memory requests, the new size queue segments 
42 are allocated in the same manner as other size queue 
segments 42, by taking the first one off the beginning of the 
size queue link list 100 (step 232). In step 224 above, the 
selected size queue 40 includes a free segment 42 of 
sufficient size, wherein that segment 42 is allocated to satisfy 
the request (step 232). The memory manager 30, then returns 
the memory address of the segment 42 to the operating 
system (step 234). 
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Upon receiving an operating system request to deallocate/ 
free a released size queue segment 42 (step 236), the 
memory manager 30 determines if the released segment 42 
is part of a borrowed file system cache buffer 46 (e.g., a 
block 97) (step 238). If not, the released segment 42 is 5 
returned to the beginning of the free memory link list 100 of 
the size queue 40 as described above (step 242). Otherwise, 
the released segment 42 is added to the end of the free 
memory Unk list 100 for that size queue 40 (step 244). This 
ensuires that the original size queue segments 42 are used in 10 
preference to the segments borrowed from a file system 
cache bxiffer 46. As a result, over time, the segments 42 used 
from borrowed FS cache buffers 46 tend to be free more than 
the original segments 42 created during size queue initial- 
ization. When an optional background trim process searches 15 
the size queues 40 for blocks 97 that were borrowed from FS 
cache 44, all segments 42 of those blocks 97 will more likely 
be free, therefore, increasing the likelihood that the bor- 
rowed block 97 can be trimmed and returned to FS cache 40, 
The memory manager 30 then returns to the operating 20 
system (step 246). 

The initial minimum sized size queue 40 represents a 
single block of memory 94 broken into same sized segments 
42. A size queue 40 that has grown includes one or more 
additional blocks 97 broken into same sized segments. The 25 
blocks are linked together by a link list 100 and attached to 
the size queue's header 90. FIG. 12 shows an example flow 
diagram of an embodiment of step 72 in FIG. 4, for an 
optional background process to perform size queue trim- 
ming. Once one or more size queues 40 grow as discussed 30 
above, a background process can periodically attempt to 
trim the size queues 40 to return borrowed memory. For each 
size queue 40 that has grown beyond a minimum established 
during system startup, the memory manager 30 selects e.g. 
idle time to begin trimming (or periodically, in order to more 35 
aggressively tune in the file server) (step 250), and examines 
the block link list 96 of the size queue 40 for blocks 97 
borrowed from FS cache 44 that can be released from the 
size queue 40; each block 97 that is marked as having been 
borrowed from the file system cache 44, is examined to 40 
determine if all the size queue segments 42 that the block 97 
has been divided into are currently free (step 252). Because 
the size queue free memory link Ust 100 is not kept in strict 
memory address order, it cannot be used to traverse the 
blocks 97. However, the original size queue segments 42 are 45 
always releaded to the beginning of the free link hst 100, and 
new growth segments 42 are always released to the end of 
the free memory link list 100, while allocations are from the 
beginning of the link list 100. Over time, the segments 42 
borrowed through size queue growth tend to be more Ukely 50 
free than the original segments 42. A block 97 that was 
borrowed from the file system cache 44 is traversed by 
examining the known memory offsets therein where alloca- 
tion headers 98 are located. The memory ofifeets are easily 
determined because all segments 42 (with the possible 55 
exception of the last in the block 97) are of fixed size. 

If all segments 42 within a borrowed block 97 (i.e., file 
system buffer 46) are free (step 254), the segments 42 are 
removed from the size queue's free memory link list 100, 
and the block 97 (buffer 46) is then removed from the size 60 
queue's block link list 96 and returned to file system cache 
44 (step 256). Otherwise, the memory manager 30 deter- 
mines if all growth segments 42 have been trimmed (step 
257), if so, the size queue pool header 90 is marked to its 
original minimum size (step 258). Otherwise, the memory 65 
manager 30 determines if any other size queue has grown in 
size (step 260). If so, steps 252-258 can be repeated, 
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Otherwise the memory manger 30 determines if all queues 
40 are back to minimum (step 262). If not, steps 250-260 
can be repeated at an appropriate time. When all size queues 
40 have been trimmed back to their original sizes the 
background process ends (step 264). 

In another version, a memory management method 
according to the present invention can be implemented in a 
storage system including a central processing unit (CPU), 
memory and at least one storage device wherein data is 
transferred to/from the storage device via at least a portion 
of the memory, wherein the memory management methods 
are performed by the CPU. The storage system can comprise 
a network server, wherein the memory manager 30 operates 
in response to calls made from one or more server resident 
programs running in the network server, where the server is 
operating under control of a network operating system 
including said memory manager 30 comprising system 
memory allocation functions callable by the one or more 
server resident programs for making desired memory allo- 
cations and deallocations. In addition to the example net- 
work filer server in which a memory management method 
and module/system according to the present invention can 
be implemented, other examples can include personal digital 
assistants, routers, subscriber management systems, com- 
puter systems with in-memory cache, embedded operating 
system controlled devices, etc. 

Further, the present invention can be implemented in 
computer systems having one or more of the following 
characteristics: the computer system includes a closed oper- 
ating system, with no outside appUcations running on the 
computer system; the computer system does not utilize 
virtual memory; performance and functionality of the com- 
puter system arc bound by in-memory cache; and/or the 
computer system encounters varying processing environ- 
ments and processing/data transfer loads. In an example 
computer system (e.g., file server) a memory management 
method according to the present invention includes one or 
more of the following features: limiting the maximum size 
of memory requests; efiScicnlly managing RAM memory, 
especially to reduce fragmentation and increase access 
speed, essential for better performance; managing competi- 
tion to maximize in-memory cache without restricting gen- 
eral purpose use memory; and optimizing memory manage- 
ment by self-tuning to adapt to different/varying processing/ 
data transfer requirements. 

Limiting memory request size is optional and is useful in 
computer systems with closed operating systems, or to only 
a portion of the operating system that is closed (i.e. the 
kernel, but not the user layer of the OS). Further, the present 
invention can be implemented in computer system which 
utilize virtual memory, for efiScient RAM management as 
described. The present invention can be implemented in 
computer systems/devices which rely upon in-memory 
cache for maximizing in-memory cache. However, the 
present invention can be implemented in computer system 
which do not use in-memory cache. Further, the present 
invention can be utilized in computer systems wherein the 
computer system includes closed operating system, or, the 
memory manager restrict memory requests to within a set 
size; the amount of in-memory cache has a direct bearing 
upon performance and/or functionality of the computer 
system; and/or the number and/or type of operations the 
computer system performs varies from time to time or from 
installation to installation. 

FIG. 13 shows a block diagram of an example architecture 
of an embodiment of a computer system 3(M) in which the 
present invention can be implemented. The computer system 
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300 includes one or more computer systems 301, wherein a 
memory manager according to the present invention can be 
implemented in one or more of the computer systems 301. 
A computer system 301 (e.g., network file server) includes 
a bus 302 or other communication mechanism for commu- 
nicating information, and a processor 304 (e.g., CPU 24 in 
FIG. 2A) coupled with the bus 302 for processing informa- 
tion. The computer system 301 also includes a main memory 
306, such as a random access memory (RAM) (e.g., memory 
26 in FIG. 2A) or other dynamic storage device, coupled to 
the bus 302. The memory 306 is managed by e.g. the 
memory manager 30. Further, a portion of the memory 306 
is used for storing information and instructions to be 
executed by the processor 304, and another portion of the 
memory 306 is used for storing temporary variables or other 
intermediate information during execution or instructions to 
be executed by the processor 304. The computer system 301 
further includes a read only memory (ROM) 308 or other 
static storage device coupled to the btis 302 for storing static 
information and instructions for the processor 304, A storage 
device 310, such as a magnetic disk (e.g. disk storage 22 in 
FIG. 2A) or optical disk, is provided and coupled to the bus 
302 for storing information and instructions. The bus 302 
may contain, for example, thirty-two address lines for 
addressing the main memory 306 or video memory. The bus 
302 can also include, for example, a 32-bit data bus for 
transferring data between and among the components, such 
as the CPU 304, the main memory 306 and the storage 310. 
Alternatively, multiplex data/address lines may be used 
instead of separate data and address lines. 

In one embodiment, the CPU 304 comprises a micropro- 
cessor manufactured by Motorola(R) such as 680x0 
processor, or a microprocessor manufactured by Int6l(R), 
such as the 80x86. or P6ntium(R) processor, or a SPARC(R) 
microprocessor from Sun Microsystems(R). However, any 
other suitable microprocessor or microcomputer may be 
utilized, based on the processing requirements for the com- 
puter system 101. The main memory 306 can comprise 
dynamic random access memory (DRAM). And video 
memory (not shown) can comprise a dual-ported video 
random access memory. 

The computer system 301 can be coupled via the bus 302 
to a display 312, such as a cathode ray tube (CRT), for 
displaying information to a computer user. An input device 
314, including alphanumeric and other keys, is coupled to 
the bus 302 for communicating information and command 
selections to the processor 304. Another type or user input 
device comprises cursor control 316, such as a mousse, a 
trackball, or cursor direction keys for communicating direc- 
tion information and command selections to the processor 
304 and for controlling cursor movement on the display 312. 
This input device typically has two degrees of freedom in 
two axes, a first axis (e.g., x) and a second axis (e.g., y) that 
allows the device to specify positions in a plane. 

According to one embodiment of the invention, the steps 
of the memory manager 30 described above, is performed by 
a computer system 301 in response to the processor 304 
executing one or more sequences of one or more instructions 
contained in the main memory 306. Such instructions may 
be read into the main memory 306 from another computer- 
readable medium, such as the storage device 310 or floppy 
disks. Execution of the sequences of instructions contained 
in the main memory 306 causes the processor 304 to perform 
the memory management process steps described herein. 
One or more processors in a multi-processing arrangement 
may also be employed to execute the sequences of instruc- 
tions contained in the main memory 306. In alternative 
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embodiments, hare-wired circuitry may be used in place of 
or in combination with software instructions to implement 
the invention. Thus, embodiments of the invention are not 
limited to any specific combination of hardware circuitry 

5 and software. 

The term "computer-readable medium" as used herein 
refers to any medium that participated in providing instruc- 
tions to the processor 304 for execution. Such a medium 
may take may forms, including but not limited to, non- 

jQ volatile media, volatile media, and transmission media. 
Non-volatile media includes, for example, optical or mag- 
netic disks, such as the storage device 310. Vblatile media 
includes dynamic memory, such as the main memory 306. 
Transmission media includes coaxial cables, copper wire 
and fiber optics, including the wires that comprise the bus 
302. Transmission media can also take the form of acoustic 
or light waves, such as those generated during radio wave 
and infrared data communications. 

Common forms of computer- readable media include, for 

2Q example, a floppy disk, a flexible disk, hard disk, magnetic 
tape, or any other magnetic medium, a CD-ROM, any other 
optical medium, punch cards, paper tape, any other physical 
medium with patterns of holes, a RAM, a PROM, an 
EPROM, a FLASH-EPROM, any other memory chip or 

25 cartridge, a carrier wave as described hereinafter, or any 
other medium from which a computer can read. 

Various forms of computer readable media may be 
involved in carrying one or more sequences of one or more 
instructions to the processor 304 for execution. For example, 

30 the instructions may initially be carried on a magnetic disk 
of a remote computer. The remote computer can load the 
instructions into its dynamic memory and send the instruc- 
tions over a telephone line using a modem. A modem local 
to the computer system 301 can receive the data on the 

35 telephone line and use an infrared transmitter to convert the 
data to an infrared signal. An infrared detector coupled to the 
bus 302 can receive the data carried in the infrared signal 
and place the data on the bus 302. The bus 302 carries the 
data to the main memory 306, from which the processor 304 

40 retrieves and executes the instructions. The instructions 
received firom the main memory 306 may optionally be 
stored on the storage device 310 cither before or after 
execution by the processor 304. 

The computer system 301 also includes a communication 

45 interface 318 (e.g., Ethernet port 28 in FIG. 2 A) coupled to 
bus the 302. "The communication interface 318 provides a 
t wo-way da ta communication .coupling to a netwoik li nk 
320 th at iTconnected to a local network 3 22. For example, 
the communication interface 318 may be an in legate d 

50 se rvices digital network (ISDN) card or a modern to prov ide 
a (Jata communication connection to a correspondi ng type of 
telepho ne line, which can comprise part of the network link 
320. As another example, t he communication interface. 318 
may be a local area network (LAN) card to provide a d ata 

55 communication connection to a compatible LAN. Wireless 
links may also be implemented. In any such implementation, 
the communication interface 318 s ends and receives e lec- 
trical electromagnetic or op tical signals that carry digital 
data streams represeniing vanous types of information. 

60 Further, the communication interface 318 can comprise a 
USB/Riner and the network link 320 mav be an antenna o r 
cabl e for connecting the computer system 301 to a cab le 
provi der, satellite provider or other terrestria l transmission 
system for receiving messages, data and program code from 

65 another source. 

The network link 320 typically provides data communi- 
cation through one or more networks to other data devices. 
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For example, the network link 320 may provide a connection mined size, then allocating the requested block from 

through the local network 322 to a host computer 324, to one among said segments, otherwise allocating the 

or more client computer 305 (e.g. Client PC 18 or Applica- requested block from another portion of the memory, 

tion Server 16 in FIG, 1), or to data equipment operated by 2. The method of claim 1, wherein step (b) further 

an Internet Service Provider (ISP) 326. The ISP 326 in turn 5 comprises the steps of: 

provides data communication services through the world in response to requests for allocation of one or more short 

wide packet data communication network now commonly term memory blocks less than the predetermined size, 

referred to as the "Internet" 328. The local network 322 and then allocating each requested block from among said 

the Internet 328 both use electrical, electromagnetic or segments. 

optical signals that carry digital data streams. The signals lO 3, Jhe method of claim 1, further comprising the steps of 

through the various networks and the signals on the network limiting the size of each allocated memory block to no more 

link 320 and through the communication interface 318, than a predetermined maximum. 

which carry the digital daU to and from the computer system 4, jhe method of claim 1, further comprising the steps of 

301, are exemplary forms or carrier waves transporting the changing the number of said data segments in said memory 

information. The computer system 301 can send/receive 15 in relation to requests for memory blocks less than the 

messages/data, including program code, through the net- predetermined size. 

work link 320 and the communication interface 318. The 5. The method of claim 4, further comprising the steps of 

received code may be executed by the processor 304 as it is changing the number of said data segments in said memory 

received, and/or stored in the storage device 310, or other in relation to requests for short term memory block alloca- 

non-volatile storage for later execution. In this manner, the 20 tions less than the predetermined size, 

computer systems 301 can obtain application code in the 6. The method of claim 4, further comprising the steps of: 

form of a earner wave. increasing the number of said data segments in said 

The example versions of the invention described herein memory in relation to increasing requests for memory; 

(e.g., memory manager 30) are implemented as logical and 

operations mcomputmg systems 301. The logical operations 2S ^^^^^^^ ^^^^^ ^j^^^, segments in said 
of the present invention can be implemented as a sequence ^ ^^j^^^^, ^^ decreasing requests for memory, 
of steps executing on the computing system 301, and as ^ ^^^j^^j ^-^^^ ^ f^^^^^ comprising the steps of: 
interconnected machme modules within the computing sys- . . , . ^ , - . 
tem 301. Hie implementation is a matter of choice and can apportiomng at least a portton of the memory for main- 
depend on performance of the a computer system 301 and/or 30 Ummg therein at least one or more data buff^^^ 
network 300, implementing the invention. As such, the «• ™<='hod of claim 7, wherem the data buffers are for 

logical operations constituting said example versions of the ^^^* ■ . , r 

. .. f J * f t.- 4. 9. The method ot claim 8, rurther CO mpnsme the steps 01 

mvention are referred to for e.g. as operations, steps or . "^^^^'^^ ^ix^i^i^u,^^ p 

modules or r using one or more of the data buffers for allocatmg memory 

^ . ' . . , - , , . 35 blocks therefrom for non-cache use. 

In this descnpUon the terrn computer system mcludes the j„ ^^^j^^^ „f ^j^j^ g j^^,^^^ comprising the steps 

computer s>^tem shown and described here, and to logic „f deallocating memory blocks allocated from the cache 

cu-cuits, dedicated computing devices, etc. The present j^^^j^ ^ cache 

invention can be implemented in a system compriang a method of claim 7. further comprising the steps of 

proces«)r(e.g., CPU) and memory. For example, referrmg to ^^^^ ^^^^^^ j^,^ segments in relation to 

FIG. 13, the pr^nt mvention can be implemented m a ^ ^^^^ predetermined size, 

computer system 301 which does not mclude one or more of jj. The method of claim 11. further comprising the steps 

thestoragedeviceSlO, the communication mterface 318, the ^f changing the number of said data segments in relation to 

ROM 108, the display 312. the input device 314, and/or the ^ ^^ 

term memory block allocations less than 

cursor control 316. ^1^^ predetermined size. 

The present invention has been described in considerable 13, xhe method of claim U, further comprising the steps 

detail with reference to certain preferred versions thereof; of changing the number of said buffers in substantially 

however, other versions are possible. Therefore, the spirit inverse proportion to changes in the number of said data 

and scope of the appended claims should not be limited to segments, in relation to memory requests, 

the description of the preferred versions contained herein. 14, xhe method of claim 7, further comprising the steps 

What is claimed is: of increasing the number of said data segments by allocating 

1. A method for managing memory, comprising the steps one or more data buffers for use as one or more additional 

of: data segments in relation to memory requests. 

(a) in response to requests for allocation of memory 15. The method of claim 14, further comprising the steps 
blocks that remain allocated for different durations, 55 of decreasing the number of said data segments by deallo- 
allocating each memory block from one of a plurality eating one or more of said additional data segments back to 
of regions in the memory based on the duration that the the data buffers. 

memory block is to remain allocated, such that: (i) in 16. The method of claim 7, further comprising the steps 

response to requests for allocation of long term of: 

memory blocks, long term memory blocks are allocated go in relation to requests for allocation of short term memory 

from a first region of the memory; and (ii) in response blocks, using one or more of the data buffers for 

to requests for aUocation of short term memory blocks, allocating short term memory blocks therefrom, 

short term memory blocks are allocated from a second 17. The method of claim 16, further comprising the steps 

region of the memory; and of deallocating said short term memory blocks allocated 

(b) maintaining a plurality of memory segments of one or 65 from the data buffers back to the data buffers. 

more sizes in the memory, and in response to a request 18. A memory manager for a computer system including 

for aUocation of a memory block less than a predeter- a central processing unit (CPU) and memory, comprising: 
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an allocator that allocates memory blocks in response to 
requests for allocation of memory blocks that remain 
allocated for different durations, by allocating each 
memory block from one of a plurality of regions in the 
memory based on the duration that the memory block 5 
is to remain allocated, wherein the allocator: (i) allo- 
cates long term memory blocks from a first region of 
the memory in response to requests for allocation of 
long term memory blocks, and (ii) allocates short term 
memory blocks from a second region of the memory in lo 
response to requests for allocation of short term 
memory blocks; and 

a controller that maintains a plurality of memory seg- 
ments of one or more sizes in the memory, and in 
response to a request for allocation of a memory block 
less than a predetermined size, allocates the requested 
block from among said segments, otherwise allocates 
the requested block from another portion of the 
memory. 

19. The memory manager of claim 18, wherein the 
controller further allocates one or more segments from 
among said segments in response to requests for allocation 
of short term memory blocks less than the predetermined 
size. 

20. Hie memory manager of claim 18, wherein the 25 
controller further changes the number of said data segments 

in said memory in relation to requests for memory blocks 
less than the predetermined size. 

21. The memory manager of claim 18, further comprising 

an allotter for apportioning at least a portion of the memory ^0 
for maintaining therein at least one or more data buffers. 

22. The memory manager of claim 21, wherein the data 
buffers are for cache use. 

23. The memory manager of claim 22, wherein the allotter 
further uses one or more of the data buffers for allocating 
memory blocks therefrom for non-cache use. 

24. The memory manager of claim 23, wherein the allotter 
further deallocates memory blocks allocated from the data 
buffers back to the data buffers. 

25. The memory manager of claim 21 wherein the con- 
troller further changes the number of said data segments in 
relation to requests for memory less than the predetermined 
size. 

26. The memory manager of claim 25, wherein the 
controller further changes the number of said data segments ^5 
in relation to requests for short term memory block alloca- 
tions less than the predetermined size. 

27. The memory manager of claim 21, wherein the 
controller further increases the number of said data segments 
by allocating one or more data buffers for use as one or more 50 
additional data segments in relation to memory requests. 

28. The memory manager of claim 27, wherein the 
controller further decreases the number of said data seg- 
ments by deallocating one or more of said additional data 
segments back to the data buffers. 55 

29. The memory manager of claim 21, wherein the allotter 
further uses one or more of the data buffers for allocating 
short term memory blocks therefrom in relation to requests 
for allocation of short term memory blocks. 

30. The memory manager of claim 29, wherein the allotter *o 
further deallocates said short term memory blocks allocated 
from the data buffers back to the data buffers. 
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31. The memory manager of claim 18, wherein the 
computer system comprises a network file, server. 

32. A computer program product for use with a computer 
system including a central processing unit (CPU) and 
memory for memory management, the computer program 
product comprising: 

a computer-readable medium; 

means, provided on the computer- readable medium, for 
allocation of memory blocks in response to requests for 
allocation of memory blocks that remain allocated for 
different durations, by allocating each memory block 
from one of a plurality of regions in the memory based 
on the duration that the memory block is to remain 
allocated, such that long term memory blocks are 
allocated from a first region of the memory in response 
to requests for allocation of long term memory blocks, 
and short term memory blocks are allocated from a 
second region of the memory in response to requests 
for allocation of short term memory blocks; and 

means, provided on the computer-readable medium, for 
maintaining a plurality of memory segments of one or 
more sizes in the memory, and in response to a request 
for allocation of a memory block less than a predeter- 
mined size, then allocating the requested block from 
among said segments, otherwise allocating the 
requested block from another portion of the memory. 

33. The computer program product of claim 32, wherein 
said means for maintaining the plurality of memory seg- 
ments further comprises means for changing the number of 
said data segments in said memory in relation to requests for 
memory blocks less than the predetermined size. 

34. The computer program product of claim 32, further 
comprising means, provided on the computer-readable 
medium, for apportioning at least a portion of the memory 
for maintaining therein at least one or more data buffers for 
cache use. 

35. The computer program product of claim 34, further 
comprising means, provided on the computer-readable 
medium, for using one or more of the data buffers for 
allocating memory blocks therefrom for non-cache use and 
deallocating memory blocks allocated from the data buffers 
back to the data buffers. 

36. The computer program product of claim 34, wherein 
said means for maintaining the data segments further 
includes means for changing the number of said data seg- 
ments in relation to requests for memory less than the 
predetermined size. 

37. The computer program product of claim 36, wherein 
said means for maintaining the data segments further 
includes means for increasing the number of said data 
segments by allocating one or more data buffers for use as 
one or more additional data segments and for decreasing the 
number of said data segments by deallocating one or more 
of said additional data segments back to the data buffers. 

38. The computer program product of claim 34, further 
comprising means, provided on the computer- read able 
medium, for using one or more of the data buffers for 
allocating short term memory blocks therefrom and for 
deallocating said short term memory blocks allocated from 
the data buffers back to the data buffers, in relation to 
requests for allocation of short term memory blocks. 

« « « * » 
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